System and method of handling requests in a multi-homed reverse proxy

ABSTRACT

Cloud service providers provide resources on a plurality of hosts some of which furthermore reside in different domains. An enhanced Reverse Proxy server is described which is configured to access hosts of multiple domains, handling client requests transparently. A request from a client to any of the supported service provider target hosts is addressed to a path in the domain of the reverse proxy server, and is formatted to include the target host domain coded as a short form name which is inserted in the path component of the request. Arguments in JavaScript calls of the response from the target host to the client are modified to ensure that future JavaScript operations generate similarly formatted requests. The enhanced Reverse Proxy translates Universal Resource Locators (URLs) of traffic between hosts of the service provider and the client in both directions accordingly.

RELATED APPLICATIONS

The present application claims benefit from the U.S. provisionalapplication Ser. No. 61/479,634 filed on Apr. 27, 2012, entire contentsof which are incorporated herein by reference.

FIELD OF THE INVENTION

The present invention relates to client-server communication in anetwork, and in particular to user authentication when client-servercommunication is mediated by a proxy.

BACKGROUND OF THE INVENTION

In computer networks, a Reverse Proxy is a type of proxy server thatretrieves resources on behalf of a client from one or more servers.These resources are then returned to the client as though theyoriginated from the Reverse Proxy itself. The user browser navigates toa Universal Resource Locator (URL) in a Hypertext Transfer Protocol(HTTP) message for example HTTP://www.mydomain.com. The Reverse Proxy atthat address, in turn, makes a request to the real web server resourceson behalf of the user, for example HTTP://www.saas.com. In order for aReverse Proxy to operate properly, it needs to take all requests fromthe client browser, and change all references for it's own URL(mydomain.com) to that of the target URL (saas.com). For example, abrowser may request a home page by issuing a GET request onHTTP://mydomain.com/index.html. The Reverse Proxy, in turn, rewrites therequest as GET on HTTP://www.saas.com. This the typical one-to-onemapping of URLs and paths between the two servers.

A number of large organizations are adopting a Single Sign-On (SSO)strategy for managing and securing access and control of theirenterprise applications. For those applications that are locallyresident and managed by the enterprise, this is fairly straightforwardto implement. Implementing a Single Sign-On infrastructure enables usersto sign in once and have access to all authorized resources. A SSOstrategy that involves cooperation between independent network entitiescooperating in SSO are termed a “federated SSO strategy”.

Numerous applications provide basic SSO functionality, for example JavaOpen Single Sign On (JOSSO) which is an open source software package.Federated SSO is facilitated for example by the Security AssertionMarkup Language 2.0 (SAML 2.0) which is a standard for exchangingauthentication and authorization data between security domains. Adescription of SAML 2.0 may be found on the web at<http://en.wikipedia.org/wiki/SAML_(—)2.0>. Another description of SSOwith SAML may be found at<http://wiki.developerforce.com/page/Single_Sign-On_with_SAML_on_Force.com≧which is a commercial website. The term federated implies that there areseveral entities, namely an Identity Provider and a Service Providercooperating in authenticating a user.

Cloud applications reside outside of the enterprise infrastructure,typically in a server providing “Software as a Service” (SaaS), andtherefore require additional security and access control considerations.Besides SSO, a number of organizations have a requirement formonitoring, moderating, and curtailing access to Internet resources byway of a Proxy or Reverse Proxy. As a result, most cloud applicationscannot use simultaneously both a federated SSO strategy, which normallyrequires direct communications between the Identity Provider for theenterprise and the Cloud application, and a Reverse Proxy, which wouldinterrupt this direct communications for SSO.

Conventional Reverse Proxy Servers are typically designed andimplemented to provide front-door load balancing for incoming traffic tobe distributed across a plurality of homogeneous web servers that areservicing the same requests.

A new challenge is to use a Reverse Proxy server to act as a gateway toa heterogeneous mix of web servers, each with a unique URL/Domain, and aset of disparate services. As cloud adoption by the enterprise continuesto grow, so does the need to monitor, moderate, and manage access tothese web-based applications and resources. The limited capabilities ofexisting Reverse Proxy servers would require the setup of separatereverse proxies on a cloud by cloud basis.

Therefore the need arises for the development of an enhanced ReverseProxy server to overcome the above mentioned limitations of existingreverse proxies.

SUMMARY OF THE INVENTION

It is an objective of the invention to provide methods and a reverseproxy system capable of being used as a gateway to a heterogeneous mixof web servers.

According to one aspect of the invention, there is provided a method forproviding a resource from one of a plurality of service provider hoststo a client device through a reverse proxy computer, comprising:employing at least one processor for:

-   -   receiving a request from the client device in the reverse proxy        computer, the request including a header comprised of:        -   a domain name of the reverse proxy computer;        -   a short form domain name representing a selected service            provider domain (domain);        -   a short form host name representing a selected service            provider host (host) in the t selected domain; and        -   a path name for locating the resource on the host;    -   translating the short form domain name into a domain name of the        host;    -   translating the short form host name into a host name of the        host; and    -   generating a modified request for transmission to the server        provider host, the modified request including:        -   the host name, the domain name, and the path name.

In the method described above, the short form domain name is analphanumeric string preceded by a forward slash character (“/”), and theshort form host name is another alphanumeric string preceded by anotherforward slash character (“/”).

The method further comprises:

-   -   modifying a document, received in the reverse proxy from the        host computer, into a modified document, including:        -   finding a reference to the domain name of the host in the            document; and        -   replacing the reference to the domain name of the host, with            the domain name of the reverse proxy, followed by a forward            slash character (“/”) and the short form name of the host;    -   transmitting the modified document to the client device.

For example, the request from the client device may be a HypertextTransfer Protocol (HTTP) GET message. Alternatively, the request fromthe client device may be contained in a Hypertext Transfer Protocol(HTTP) POST message.

In an embodiment of the invention, the document is a Hypertext MarkupLanguage (HTML) document.

The method further comprises:

-   -   finding within the document a subroutine call having as        arguments a Universal Resource Locator (URL) of one of the        plurality of the service provider hosts and a path name; and    -   replacing said subroutine call with a modified subroutine call,        comprising:        -   replacing said URL with the URL of the reverse proxy; and        -   generating a modified path name by inserting another forward            slash character (“/”) followed by the short form name of            said one of the plurality of the service provider hosts in            front of the path name.

The method further comprises repeating the steps finding and replacingsaid subroutine for all subroutine calls in the document. In oneembodiment, the subroutine call is a JavaScript function call.

The method further comprises:

-   -   receiving a request from the client in the reverse proxy, the        request including a header which does not correspond to any        pattern found in a configuration file of the reverse proxy;    -   resolving the request by performing the following steps until        the selected domain and the selected host for obtaining the        resource is determined, including:        -   searching a short form name in the header and translating            the short form name into the selected domain name, and        -   provided said short form name is found in the configuration            file, searching a path name in a content paths definitions            file of the reverse proxy to determine the selected host,            provided the path name is found in the content paths            definitions file, thereby finding the selected domain and            the selected host; and    -   generating a modified request for transmission to the server,        the modified request including the selected domain name, the        selected host name and the path name, provided the selected        domain and the selected host have been determined.

The step of resolving further comprises determining both the selecteddomain and the selected host from a referrer URL that is located in therequest, thereby finding the selected domain and the selected host.

The step of resolving further comprises using a home domain of theservice provider as the selected domain and a world wide web (www)server as the selected host, thereby determining the selected domain andthe selected host.

According to yet another aspect of the invention, there is provided areverse proxy computer for providing a resource from one of a pluralityof service provider hosts to a client device, the reverse proxy computercomprising:

-   -   a processor; and    -   a memory having computer readable instructions stored thereon,        causing the processor to:    -   receive a request from the client device in the reverse proxy        computer, the request including a header comprised of:        -   a domain name of the reverse proxy computer;        -   a short form domain name representing a selected service            provider domain (domain);        -   a short form host name representing a selected service            provider host (host) in the selected domain; and        -   a path name for locating the resource on the host;    -   translate the short form domain name into a domain name of the        host;    -   translate the short form host name into a host name of the host;        and    -   generate a modified request for transmission to a service        provider, the modified request including:        -   the host name, the domain name, and the path name.

The short form domain name is an alphanumeric string preceded by aforward slash character (“/”), and the short form host name is anotheralphanumeric string preceded by another forward slash character (“/”).

The reverse proxy computer further comprises computer readableinstructions stored in the memory, causing the processor to:

-   -   modify a document, received in the reverse proxy from the host        computer, into a modified document, including:        -   finding a reference to the domain name of the host in the            document; and        -   replacing the reference to the domain name of the host, with            the domain name of the reverse proxy, followed by a forward            slash character (“/”) and the short form name of the host;    -   transmit the modified document to the client device.

In the reverse proxy computer described above, the request from theclient device is either a Hypertext Transfer Protocol (HTTP) GETmessage, or contained in a Hypertext Transfer Protocol (HTTP) POSTmessage.

The document is a Hypertext Markup Language (HTML) document, anExtensible Markup Language (XML) document, or a JavaScript ObjectNotation (JSON) document.

The reverse proxy computer further comprises computer readableinstructions stored in the memory, causing the processor to:

-   -   find within the document a subroutine call having as arguments a        Universal Resource Locator (URL) of one of the plurality of the        service provider hosts and a path name; and    -   replace said subroutine call with a modified subroutine call,        including:        -   replacing said URL with the URL of the reverse proxy; and        -   generating a modified path name by inserting another forward            slash character followed by the short form name of said one            of the plurality of the service provider hosts in front of            the path name.

Conveniently, the subroutine call is a JavaScript function call.

According to yet another aspect of the invention, there is provided areverse proxy computer for providing a resource from one of a pluralityof service provider hosts to a client device, the reverse proxy computercomprising:

-   -   a processor;    -   a memory having computer readable instructions stored thereon        for execution by the processor, forming:        -   a forward Universal Resource Locator (URL) translator module            having instruc-tions for:        -   receiving a request from the client device in the reverse            proxy computer, the re-quest including a header comprised            of:            -   a domain name of the reverse proxy computer;            -   a short form domain name representing a selected service                provider domain (domain);            -   a short form host name representing a selected service                provider host (host) in the selected domain; and            -   a path name for locating the resource on the host;        -   translating the short form domain name into a domain name of            the host;        -   translating the short form host name into a host name of the            host; and        -   generating a modified request for transmission to the server            provider host;        -   the modified request including:            -   the host name, the domain name, and the path name.

In the reverse proxy computer described above, the short form domainname is an alphanumeric string preceded by a forward slash character(“/”), and the short form host name is another alphanumeric stringpreceded by another forward slash character.

The reverse proxy computer further comprises a content modifier modulehaving computer readable instructions stored in the memory for:

-   -   modifying a document, received in the reverse proxy from the        host computer, into a modified document, including:        -   finding a reference to the domain name of the host in the            document; and        -   replacing the reference to the domain name of the host, with            the domain name of the reverse proxy, followed by a forward            slash character (“/”) and the short form name of the host;    -   transmitting the modified document to the client device.

The request from the client is a Hypertext Transfer Protocol (HTTP) GETmessage, or the request from the client is contained in a HypertextTransfer Protocol (HTTP) POST message, and the document is a HypertextMarkup Language (HTML) document.

In the reverse proxy computer, the content modifier module further hasinstructions for:

-   -   finding within the document a subroutine call having as        arguments a Universal Resource Locator (URL) of one of the        plurality of the service provider hosts and a path name; and    -   replacing said subroutine call with a modified subroutine call        by:        -   replacing said URL with the URL of the reverse proxy; and        -   generating a modified path name by inserting another forward            slash character followed by the short form name of said one            of the plurality of the service provider hosts in front of            the path name.

For example, the subroutine call is a JavaScript function call.

In the reverse proxy computer, the forward URL translator module furtherhas instructions for:

-   -   receiving a request from the client in the reverse proxy, the        request including a header which does not correspond to any        pattern found in a configuration file of the reverse proxy;    -   resolving the request by performing the following steps until        the selected domain and the selected host for obtaining the        resource is determined, including:        -   searching a short form name in the header and translating            the short form name into the selected domain name, and        -   provided said short form name is found in the configuration            file,        -   searching a path name in a content paths definitions file of            the reverse proxy to determine the selected host, provided            the path name is found in the content paths definitions            file, thereby finding the selected domain and the selected            host; and    -   generating a modified request for transmission to the server,        the modified request including the selected domain name, the        selected host name and the path name, provided the selected        domain and the selected host have been determined.

The forward URL translator module further comprises instructions fordetermining both the selected domain and the selected host from areferrer URL that is located in the request, thereby finding theselected domain and the selected host.

The forward URL translator module further comprises instructions forusing a home domain of the service provider as the selected domain and aworld wide web (www) server as the selected host, thereby determiningthe selected domain and the selected host.

Accordingly, methods and a reverse proxy computer have been providedwhich can handle a heterogeneous mix of web servers.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the invention will now be described, by way of example,with reference to the accompanying drawings in which:

FIG. 1 illustrates a single-sign-on system 100 for implementingfederated Single Sign-ON (SSO) according to a first embodiment of theinvention;

FIG. 2 shows a message diagram 200 illustrating “IdentityProvider-Initiated” login as an example operation of SAML federatedauthentication with a Reverse Proxy according to the invention;

FIG. 3A shows a “Identity Provider-Initiated” login flow chart 300corresponding to the message diagram 200 of FIG. 2;

FIG. 4 is a flow chart illustrating individual steps of the step 308 ofFIG. 3;

FIG. 5 illustrates a multi-IDP system 500 for implementing federatedSingle Sign-ON (SSO) for multiple sets of clients according to anotherembodiment of the invention;

FIG. 6 illustrates an exemplary multi-host Reverse Proxy system 600according to yet another embodiment of the invention;

FIG. 7A shows a data flow diagram 700 as an example of URL manipulationsin the PRS Reverse Proxy 112 of FIG. 1;

FIG. 7B shows code examples of the HTML page 712, and the modified HTMLpage 714 of FIG. 7A;

FIG. 7C shows a flowchart 750 of the Response Processing Function 706 ofFIG. 7A;

FIG. 8 shows a domain resolution method 800, performed in the PRS-RP 112for resolving a current URL of an HTTP request, according to theinvention;

FIG. 9 shows a sample domain and host configuration table according tothe invention;

FIG. 10 shows an excerpt of a sample content paths definitions fileaccording to the invention;

FIG. 11 shows a flowchart of a Process for Preserving JavaScript URLs1100, according to the invention; and

FIG. 12 shows a block diagram 1200 of the PRS Reverse Proxy 112,according to the invention.

DETAILED DESCRIPTION OF THE EMBODIMENTS OF THE INVENTION

With the objective to overcome the limitations of reverse proxies of theprior art, an enhanced Reverse Proxy server has been developed by thePerspecSys corporation. This enhanced Reverse Proxy server will bereferred to as a Perspecsys (PRS) Reverse Proxy, features andembodiments of which are described in the following.

To resolve the apparent incompatibility of federated SSO to operate inconjunction with a Reverse Proxy, the invention proposes a system andmethods wherein a modified Reverse Proxy (termed PerspecSys ReverseProxy) behaves as an Intercepting Proxy, inserting itself in the middleof the trusted authentication conversation between the SSO IdentityProvider and the Cloud application. In this way, the PRS Reverse Proxycan be used for its original purposes for managing access to the Cloudapplications, i.e. applications provided and running in SaaS servers,while not hindering the security and user management that SSO providesfor authentication with the Cloud application.

Single Sign-ON (SSO)

FIG. 1 illustrates a single-sign-on system 100 for implementingfederated Single Sign-ON (SSO) according to a first embodiment of theinvention. The single-sign-on system 100 comprises an enterpriseinstallation 102 (also simply referred to as enterprise 102), a serviceprovider computer, also simply referred to as “service provider”(abbreviated SP) 104, and an identity provider computer, also simplyreferred to as “identity provider” (abbreviated IDP) 106, the enterprise102, the SP 104, and the IDP 106 being connected to the Internet 108.

The enterprise 102 includes a client device 110, also simply referred toas “client” 110, an enhanced Reverse Proxy computer to be referred inthe following as a PerspecSys (PRS) Reverse Proxy computer, also simplyreferred to as “PRS Reverse Proxy” (abbreviated PRS-RP) 112, andoptionally a firewall 114.

The client device 110 may be a personal computer, a work station, alaptop computer, a “smart” device such as a mobile device or a tablet,or any other device capable of including a web browser application 118.

The SP 104 may be a server that is implemented on at least one computeror on a number of hosts each of which is a distinct computer. Similarly,the IDP 106 may be a server that is implemented on at least one computeror on a number of hosts each of which is a distinct computer.

The term computer is understood to mean a device that includes aprocessor, and computer-readable instructions stored in acomputer-readable memory for execution on the processor. Any of thecomputers used in the present invention may be a general purposecomputer such as any of a number of commercially available computers.Alternatively, each computer may be a specialized computer, or ahardware device such as a programmable application specific device.

The PRS-RP 112 is a computer equipped with software programs forenabling the single-sign-on feature of the first embodiment of theinvention, as well as other embodiments to be described below. Thefunctionality of the PRS-RP 112 may also be implemented with anApplication Specific Integrated Circuit (ASIC) or a number of ASICs.

A hardware description of the PRS-RP 112 in the form of a computer isprovided in FIG. 12 below.

Overview of SAML

The Security Assertion Markup Language (SAML) provides a secure,Extensible Markup Language (XML)-based solution for exchanging usersecurity information between an enterprise (i.e. the enterprise 102, ormore precisely a one or more users in the enterprise 102, such as theclient 110), an identity provider (i.e. the IDP 106) and a serviceprovider (i.e. the SP 104) which may be a Cloud application providingSaaS services. SAML 2.0 supports World Wide Web Consortium (W3C) XMLencryption and service-provider-initiated web single sign-on exchanges.This allows SaaS service providers such as the SP 104 to query theidentity provider for authentication. Similarly, SAML 2.0 providesidentity provider initiated web single sign-on exchanges. SAML 2.0 alsoincludes a useful feature called “single logout” which defines amechanism for logging out of all service providers quickly and easily.

The three entities involved in a SAML 2.0 transaction are

-   -   the identity provider 106 (the asserting party),    -   the service provider 104 (the party relying on the assertion),        and    -   the user, i.e. the client 110 (the subject of the assertion).

The identity provider 106 is the authority system that providesinformation confirming the user's identity. The service provider 104 isthe system that trusts the identity provider's user information, anduses this information data to provide access to the service orapplication. The user with their identity information are known as the“subject”.

The transaction from the identity provider 106 to the service provider104, is called a SAML assertion. The structure of the SAML assertion isdefined by a XML schema that is specified by the Organization for theAdvancement of Structured Information Standards (OASIS) SAML standard.The SAML assertion contains header information, and statements about thesubject in the form of attributes and conditions such as a start andlogout Universal Resource Locator (URL).

Web browser SSO is SAML's most widely used feature and is typically usedin conjunction with the Hypertext Transfer Protocol (HTTP) POST bindingand authentication request protocol. Web browser SSO may be initiated bythe identify provider or by the SaaS application if a user's session hasnot been established. If initiated by the identity provider, theassertion is signed.

In computer networks, a Reverse Proxy is a type of proxy server thatretrieves resources on behalf of a client from one or more servers.These resources are then returned to the client as though theyoriginated from the Reverse Proxy itself. The term “resource” itself isa collective term, that is used in the current context to refer to dataprovided by the service provider to a user or client, as well asservices performed by the service provider on behalf of the client suchas, for example, executing an application on data provided by theclient, with results returned to the client.

With Identity Provider Initiated Login, where a user starts directly attheir identity provider, logs in, and is then redirected to a landingpage at the service provider, difficulties can arise when using aconventional Reverse Proxy server. The difficulty is with the contentsof the SAML assertion which contains specific information to the actualSaaS application and it's URLs, including the return URL (i.e. the URLof the client). This will not match the URL provided by the ReverseProxy (i.e. the URL of the Reverse Proxy). As a result, the assertionwill fail, and the user will be unable to log into the actual webresource through a conventional Reverse Proxy.

This difficulty is overcome by the enhanced Reverse Proxy 112 as will bedescribed in the following.

System Overview

Each of the client device 110, the PRS-RP 112, and the optional firewall114 may each be represented physically by distinct computers,interconnected through a private network 116. Alternatively, the PRS-RP112 and the optional firewall 114 may run on the same compute platform.

Without limitation, the private network 116 may be a local network, avirtual private network over the Internet 108, or any means forproviding communication channels between the client device 110, thePRS-RP 112, and the internet 108 through the optional firewall 114.

A conventional Reverse Proxy may often be directly associated with aservice provider installation, for the purpose of providing resourcesfrom one or more servers to any client over the internet. A list ofcommon uses of reverse proxies may be found in

<http://en.wikipedia.org/wiki/Reverse_proxy>.

The PRS-Reverse Proxy 112 of the single-sign-on system 100 on the otherhand is directly associated with an individual enterprise, performing asa local proxy for one or more client devices 110, as well as acting asReverse Proxy for one or more servers of the Service Provider 104.

Typically, a connection between the client device 110 and the Internet108 is provided through the optional firewall 114. The optional firewall114 may be a conventional firewall for protecting the enterpriseinstallation 102 from intrusion and malicious network traffic, and isotherwise not of interest in the present invention.

Authenticating the client device 110 into the SP 104 is provided throughthe PRS-RP 112, the functionality of which is the subject of anembodiment of the present invention. Once authenticated, the clientdevice 110 has access to resources on the SP 104.

However, before the client 110 is able to use services provided by theSP 104, that require authorization, the “identity” of the client 110must be provided by the IDP 106, and authenticated and accepted by theSP 104. This is what is meant by “authentication”. The “identity” is an“assertion” that the IDP 106 provides to the client 110 once the IDP 106has validated the client's identity. This forms a trust chain betweenthe IDP 106 and the target service provided by the SP 104, as the clienttakes the assertion provided by the IDP 106 and uses it asauthentication to access the service provider, instead of having to login again with a different set of credentials to the service provider 104for authentication. The SAML 2.0 protocol provides the process andstandard by which this authentication trust chain is established andrealized to allow the client to authenticate once, against the IDP 106,and then use the assertion to access other services without having tore-authenticate, as the service providers accept the provided assertionas proof that an authentication check has already successfully beenperformed by the IDP.

Before this SSO authentication method can work, the enterprise, onbehalf of the client 110, has established a trust relationship with theIDP 106 in a separate off-line or out-of-band process, by providing theIDP 106 with a unique client-specific key. Similarly the SP 104 has anindependent trust relationship with the IDP 106. The SSO authenticationmethod then provides the ability for different enterprises and multipleservice providers to dynamically establish secure one-on-onerelationships.

As shown in the following, novel functionality of the PRS-RP 112provides transparent forwarding of authentication messages and othermessages between the client 110 and the SP 104, in cooperation with theIDP 106.

Briefly, the way the IDP 106 and SP 104 trust each other is that theyshare keys for encryption and decryption, where the keys wereestablished when the SSO implementation was first configured. With theseencryption keys, the IDP is able to perform the following.

-   -   Authenticate the client.    -   Upon successful authentication of the client, the IDP 106 can        generate an “assertion” that the client 110 can then use to        access service providers, for example the SP 104.    -   The client 110 can present the assertion to the service provider        (the SP 104 for example) in place of performing another type of        authentication (e.g. username/password login).    -   The service provider (the SP 104) opens the assertion document,        and sees a clear-text XML component, as well as a digital XML        signature which it not encrypted as it is a one-way hash type        signature. A document providing details on XML signature syntax        and processing may be found at        <http://www.w3.org/TR/xmldsig-core/>. The digital XML signature        is verified by hashing the clear-text XML content and comparing        the resulting signature with the digital XML signature.

SAML 2.0 provides for a number of methods for performing authenticationmessage exchanges, including HTML POST bindings, which is implied in thefollowing. Other methods such as HTTP Redirect Binding, HTTP ArtifactBinding, and SAML URI Binding are also possible and are included in thescope of the present invention all of which involve the passing of aSAML 2.0 assertion response. A document specifying Bindings for version2 of the OASIS Security Assertion Markup Language (SAML 2.0) may befound athttp://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdfwhich is part of the OASIS Standard, 15 Mar. 2005.

Note that in the conventional SAML SSO scheme, there are three players:a user, an identity provider, and a service provider, which share thesame encryption key. However, in the single-sign-on system 100 there aretwo overlapping sets of players:

-   -   the IDP 106 and the PRS-RP 112, sharing one encryption key (an        encryption key “A”), and    -   the PRS-RP 112, and the SP 104, sharing a second encryption key        (an encryption key “B”).

The client 110 does not actually have the key used for the XML signaturegeneration. The client 110 transmits the SAML authentication request andSAML response with the assertion (depending on whether it is IDPinitiated as described in the example here or SP initiated) but does notuse any key for signing or authenticating. The client is only a conduitand only forwards the signed assertion response from the IDP 106 to thePRS-RP 112.

It is preferable and usual, but not strictly necessary, that theencryption key “A” differs from the encryption key “B”. The encryptionkey “B” is required to use services such as a SaaS application on the SP104. While only a single encryption key “B” is described, it is notedthat different applications running on the same SP 104 may requiredifferent encryption keys for authentication, depending on how manyinstances of the application are used. For example a production instanceand sandbox instance may both be on the same SP 104, but are using twodifferent single sign-on settings, therefore requiring different keys,one for the production instance, another one for sandbox instance.

FIG. 2 shows a message diagram 200 illustrating an “IdentityProvider-Initiated” login as an example operation of SAML federatedauthentication with a Reverse Proxy, showing the actors involved (theclient 110, the IDP 106, the PRS-RP 112, and the SP 104) in a messageexchange including in time sequence the following messages:

-   -   a “User login” message 202 from the client 110 to the IDP 106;    -   an “IDP assertion response” message 204 from the IDP 106 to the        client 110;    -   an “Assertion to PRS-RP” message 206 from the client 110 to the        PRS-RP 112;    -   a “Revised assertion” message 208 from the PRS-RP 112 to the SP        104;    -   an “Assertion result” message 210 from the SP 104 to the 112;        and    -   a “Revised assertion result” message 212 from the PRS-RP 112 to        the client 110.

While a detailed description of only the “Identity Provider-Initiated”login method as a SAML federated authentication method with a ReverseProxy is disclosed in the first embodiment of the invention, it isunderstood that other types of SAML authentication methods with aReverse Proxy, including “Service Provider-Initiated” login are readilyderived from the present disclosure, and are within the scope of thepresent invention.

The message sequence 202 to 212 illustrates “IdentityProvider-Initiated” login in which the login of the client 110 to the SP104 is first directed to the IDP 106 which provides the client 110 withan authentication certificate with which the client 110 is then able toassert his identity with the SP 104 through the PRS-RP 112. Each of themessages 202 to 212 is shown as a single message in FIG. 2 in thishigh-level view. In some cases the term “message” may refer to more thanone message or a message exchange, as will be appreciated bypractitioners skilled in the art of web design.

Alternate message sequences are also possible. For example in “ServiceProvider Initiated” login, the initial login is directed to the serviceprovider which subsequently obtains confirmation of the clients identitydirectly from the identity provider. “Service Provider Initiated” loginis not further described here.

The operation of “Identity Provider-Initiated” login illustrated by themessage diagram 200 may further be considered as a sequence of stepsshown in FIG. 3.

FIG. 3A shows a “Identity Provider-Initiated” login flow chart 300corresponding to the message diagram 200, including steps:

-   302 “User Login via IDP”;-   304 “Send IDP Assertion Response”;-   306 “Send Assertion to Reverse Proxy”;-   308 “Send Revised Assertion to Service Provider”; and-   310 “Return Requested Resource”.

The steps 302 to 308 correspond directly with respective messages 202 to208 of FIG. 2. After a successful progress through the steps 302 to 308,the requested resource in the SP 104 is returned in the step 310 to theclient 110 which is now logged in (state 312) with the SP 104.

At the Step 302 “User Login via IDP”, the client 110 requestsauthentication to the resources of the SP 104 with the “User login”message 202 sent to the IDP 106.

This step may occur as a result of redirection from the SP 104 (in“Service Provider Initiated” login), directly via navigation from theuser's browser as shown here, or via Application Programming Interface(API) calls from a user application programs. The step 302 may also beperformed through a separate entry form requesting login credentials, atwo-factor authentication mechanism, or a previous IDP authenticationsession wherein the IDP 106 is part of a larger trust chain and wherethe client already has an assertion provided to it from another IDP.Another example of requesting login to the service provider via the IDPmight be coupled with the username/password request when logging intothe workstation, or any authentication mechanism that the client wishesto use in order to formally establish the identity of the requestingclient.

At the Step 304 “Send IDP Assertion Response”, the IDP 106, uponsuccessful authentication of the user, generates an assertion in theform of a XML payload back to the requesting client's browser. Thistypically includes a redirection to the actual Service Provider's URL(the SP 104) that is to receive the Assertion.

The Assertion itself contains two components:

-   -   1) The actual assertion, in the form of a XML document, and    -   2) An assertion signature, that is essentially an encrypted        version of the XML document.

Since the signature is an encryption, the Service Provider 104 must havebeen provided with a key during the initial configuration of the SingleSign On implementation.

In the case of the single-sign-on system 100 however, the PRS ReverseProxy 112 appears to be the Service Provider to the IDP 106 and theclient browser 118. The key shared between the actual IDP 106, and thePRS Reverse Proxy 112 for this purpose must be the encryption key “A”.This key which is typically embedded within a certificate, is used todecrypt the signature component of the assertion, and validate it'sauthenticity against the XML component.

As indicated above, the initial configuration of the Single Sign Onimplementation must include the establishment of a key that is sharedbetween the IDP 106 and the PRS-RP 112 (the encryption key “A”), andanother, different shared key between the IDP 106 and the SP 104 (theencryption key “B”).

The steps 302 and 304 constitute a complete IDP authentication sessionfor the client 110. Once the client has authenticated against the IDP106, and gets provided with the assertion. The client can then use thisassertion repeatedly, even with different service providers, providedthose service providers have already been configured to acceptassertions from the same IDP 106, by virtue of sharing of the encryptionkey “A”.

At the Step 306 “Send Assertion to Reverse Proxy”, the original resourceconfiguration of the IDP 106 identifies the PRS Reverse Proxy 112 as theService Provider. In this way, the user's browser posts the assertionand all subsequent resource requests to the PRS Reverse Proxy 112.

Within the assertion itself, the IDP 106 has provided a “Return URL”.When working with some specific Cloud SaaS solutions such assalesforce.com for example, this Return URL must reflect a validsalesforce.com domain address, otherwise, the assertion will berejected. However, since the user's browser in the client 110 is in factcommunicating with the SaaS application of the SP 104 via the PRSReverse Proxy 112, the Return URL will not reflect the SaaS domain—itwill reflect the domain of the PRS Reverse Proxy 112.

At the Step 308 “Send Revised Assertion to Service Provider”, the PRSReverse Proxy 112 changes the Return URL to an actual SaaS applicationURL of the Service Provider. While this is a normal activity for aconventional Reverse Proxy Server (exchanging URL's between a re-questerand a provider), the Assertion's signature must also change.

By having the ability to change the Assertion's signature, the PRSReverse Proxy 112 differs from a conventional Reverse Proxy Server. ThePRS-RP 112 and now acts as the Service Pro-vider from the point of viewof the actual IDP 106 and client browser 118, consuming the origi-nalAssertion by decrypting the signature, and modifying the assertion toreflect any required URL changes required to perform standard ReverseProxy operations. This means changing all URL references referring tothe PRS-RP 112, to URL references referring to the actual SaaS Ser-viceProvider, i.e. the SP 104. These changes to the XML document are thenencrypted using the different encryption key “B” that is shared betweenthe PRS Reverse Proxy 112 and the SP 104 into a revised signature withwhich to sign the Assertion.

FIG. 3B illustrates an assertion conversion process 350, including anAssertion 352, comprising a clear text section 354 and a signaturesection 356, and a Revised Assertion 358, comprising a revised cleartext section 360 and a revised signature section 362. The clear textsection 354 includes: a Source URL (Client) 364; a Destination URL(Proxy) 366; and an Other Data section 368. The revised clear textsection 360 includes: a Source URL (Proxy) 370; a Destination URL(Service Provider) 372; and the (same) Other Data section 368.

The SAML AuthRequest is a XML document in clear text, the term “cleartext” referring to hu-man readable ASCII text for example. The assertionsent by the client device 110 includes the XML document (the clear textsection 354) and a signature (the signature section 356) which is ineffect an encrypted version of the XML document, i.e. an encryptedversion of the clear text, the encryption having been originally madewith a first encryption key “A”, which is a random string of bits havingcertain properties. Encryption, and encryption with keys, is a wellknown technique of the field of cryptography.

The XML document of the Assertion includes a first URL, which is the URLof the requester, i.e. the client device 110, shown as the Source URL(Client) 364, and a second URL shown as the Destination URL (Proxy) 366,which is the URL of the destination of the client's assertion re-quest,i.e. the PRS-RP 112, to which the assertion is sent.

After validation, the assertion is changed in the step 308 “Send RevisedAssertion to Service Provider” into a revised assertion. Validation isdone in the PRS-RP 112 by re-encrypting the clear text section 354 usingthe first encryption key “A”, to generate a test signature 374, andcomparing the test signature 374 with the original signature 356.

The revised assertion 358 includes the revised clear text section 360,which comprises the Source URL (Proxy) 370 identifying the PRS-RP 112,that is copied from the Destination URL (Proxy) 366 of the clear textsection 352, and a third URL shown as the Destination URL (ServicePro-vider) 372, which is the URL of the destination of the revisedassertion, i.e. the SP 104, to which the assertion is sent. The OtherData section in the revised clear text section 358 is unchanged from thecorresponding Other Data section in the original clear text section 352.

In the revised assertion 358, the source URL, i.e., the Source URL(Proxy) 370, makes the PRS-RP 112 appear as the requester of the revisedassertion 358. The revised signature 362 of the re-vised assertion 358is computed in the PRS-RP 112 using a second encryption key “B”.

FIG. 4 is a flow chart illustrating individual steps of the step 308“Send Revised Assertion to Service Provider” which is performed in anAssertion Processing Module (see Assertion Processing Module 1214, FIG.12) of the PRS Reverse Proxy 112, including steps:

-   402 “Receive assertion from client”;-   404 “Validate assertion with key A”;-   406 “Is assertion valid?”;-   408 “Revise URLs of assertion”;-   410 “Encrypt revised assertion with key B”; and-   412 “Forward revised assertion to SP”.

At the Step 402 “Receive assertion from client”, an “original assertion”is received from the client 110. It is of no consequence when or how theoriginal assertion had been obtained by the client 110, but it isassumed that it was provided by the IDP 106 as a result of the initialuser login.

At the Step 404 “Validate assertion with key A”, the signature part ofthe original assertion is validated using the encryption key “A” that isshared between the IDP 106, and the PRS_RP 112.

Validation of the XML Signature is based comparing it with a testsignature generated using key “A”. If the XML Signature matches the testsignature, the contents of the assertion have been validated. For moredetails on XML signature syntax and processing, please refer to thedocument at <http://www.w3.org/TR/xmldsig-core/>.

At the Step 406 “Is assertion valid?”, the decrypted original signatureis validated against the “actual” assertion, i.e. the unencrypted XMLdocument of the original assertion is compared with the decryptedoriginal signature, and the decrypted original signature is discarded.

If they match (exit “Yes” from step 406), execution continues with thefollowing step 408, otherwise (exit “No”), the original assertion isdiscarded, the operation fails, and a validation failure may berecorded.

At the Step 408 “Revise return URL of assertion” all URL values in theoriginal assertion, that is all URL values in the XML document, thatrefer to the PRS-RP 112 are replaced with the URL of the SP 104. Thisaction creates a revised XML document for the “revised assertion” whichdiffers from the original assertion. The revised XML document may alsobe referred to as a “revised clear text”.

At the Step 410 “Sign revised assertion with key B”, the revised XMLdocument is signed with a new signature based on the encryption key “B”,thus forming the encrypted revised assertion which includes the revisedXML document (a revised “actual” assertion) and the new signature.

At the Step 412 “Forward revised assertion to SP”, the revised assertionis sent to the service provider 104. At this point, the identity of theoriginal client 110 is no longer visible in the assertion, and the PRSReverse Proxy 112 has taken the client's place as far as the SP 104 isconcerned.

The reader's attention is now directed back to FIG. 3.

At the Step 310 “Return Requested Resource”, the SaaS Service ProviderSP 104 validates the revised assertion, and sends back a response,containing a Return URL for the SaaS Service Pro-vider. The response(corresponding to the Assertion result 210 of FIG. 2) is intercepted bythe PRS Reverse Proxy 112, and modified by changing the response URL toreflect a URL appropri-ate for operation of the PRS Reverse Proxy infront of the SaaS Service Provider. This revised response (the Revisedassertion result 212 of FIG. 2) is then sent back to the client browser118 in response to the original request.

The result from the service provider is a “Redirect URL” message (HTTP302) to the home page of the SP 104. No more key replacement orvalidation is required. The Reverse Proxy is now doing it's normal jobof changing normal URLs to Reverse Proxy URLs as would be the normalfunctioning of any Reverse Proxy.

After login, the client 110 is able to use the services of the serviceprovider 104 by having all traffic forwarded through the PRS ReverseProxy 112. Any encrypted traffic over Secure Socket Layer (SSL) tunnelsthrough the PRS Reverse Proxy 112 will then be intercepted in the PRSReverse Proxy 112, and all URL references to itself will be replacedwith URLs of the domains of the client 110 or the service provider 104respectively, depending on the direction of the traffic. Thisfunctionality is no different from that of a conventional Reverse Proxy.What is different and novel in the present invention, are the stepsdescribed above which enable SAML 2.0 authentication for single sign-onthrough the PRS Reverse Proxy.

Multiple Clients

Although shown with only a single client 110 in FIG. 1, it is understoodthat the single-sign-on system 100 is capable of providing SSOcapability for any number of clients 110 through a single PRS-RP 112.

In a number of situations however, a Service Provider such as a cloudapplication like salesforce.com for example, may be required to beshared within an organization, potentially across a plurality ofjurisdictions. Typically, each of the users, that is each client 110, ofthe Service Provider is then required to maintain their own SingleSign-On implementation, potentially to be authenticated with a separateFederated SAML2 Identity Provider.

The single-sign-on system 100 of FIG. 1 only uses a single pair ofencryption keys for signing the SAML assertions, the encryption key “A”between the client 110 and the PRS-RP 112, and the encryption key “B”between the PRS-RP 112 and the SP 104. The encryption key “B” enablesthe PRS-RP 112 to represent the one or several clients 110 to the SP104. This key which is provided by an Identity Provider (not shown, andnot necessarily the IDP 106 of FIG. 1) is shared between the PRS ReverseProxy 112 and the Service Provider 104. However, with multiple clientsacross a plurality of jurisdictions wishing to share the ServiceProvider resources, it is either impractical or impossible trying toalso share the encryption keys “A” across the plurality of IDPs.

The solution is to pair a dedicated PRS Reverse Proxy with each separateIDP, such that the individual IDPs can establish a unique encryption keyshared exclusively by the IDP and its corresponding PRS Reverse Proxyand the clients using the PRS Reverse Proxy, while all the Reverse ProxyServers share encryption keys with one another and the actual ServiceProvider. This technique essentially establishes a many-to-onerelationship of encryption keys from IDPs to a single encryption keyused by the Service Provider.

FIG. 5 illustrates a multi-IDP system 500 for implementing federatedSingle Sign-ON (SSO) for multiple sets of clients according to anotherembodiment of the invention.

The multi-IDP system 500 shows the single Service Provider 104 connectedto a plurality of n dedicated PRS-RP servers 502.i, i=1 to n. Each ofthe dedicated PRS-RP servers 502.i is connected to a number of clients110 and is configured to process assertions from clients using acorresponding one of a plurality of n Identity Providers (IDP.1 toIDP.n), reference numeral 106.i.

Each of the dedicated PRS-RP servers 502.i includes two encryption keyrepositories, a client side repository 504.i and a service provider (SP)side repository 506. The encryption key repositories 504.i and 506 maybe stored in persistent storage (see Key Store 1222 of FIG. 12 below).The client side repository 504.i in each respective dedicated PRS-RPservers 502.i is adapted to hold a set of encryption keys “A.i”,corresponding to the encryption key “A” of the single-sign-on system100, where the individual encryption keys “A” in the set “A.i”correspond to the individual authenticated clients 100 using thecorresponding dedicated PRS-RP servers 502.i to which they areconnected.

The multi-IDP system 500 of FIG. 6 is a generalization of thesingle-sign-on system 100 of FIG. 1. FIG. 6 indicates distinct groupings508.i, i=1 to n, indicative of jurisdictions or organizational divisionswhich give rise to the requirement of using a different identityprovider for each group.

Not shown, but implied in FIG. 6 are optional firewalls, and privatenetworks and the internet, to provide connectivity analogous to suchelements in FIG. 1.

Without loss of generality, each client 110 in each groupings 508.i isshown connected only to a specific one of the dedicated PRS-RP servers502.i and the corresponding IDP.i, but in practice any client 110 mayalso be able to access any other of the dedicated PRS-RP servers 502.ias long as they can also access the corresponding IDP.i.

In order to permit any of the clients 110 to access the SP 104 throughany of the dedicated PRS-RP servers 502.i, it is then necessary thatevery dedicated PRS-RP server 502.i is configured with all n IdentityProviders IDP.i.

The service provider side repository 506 holds a single key, theencryption key “B”, which is shared with the Service Provider 104, andwhich was established when the multi-IDP system 500 was configured.

FIG. 5 shows individual dedicated PRS-RP servers 502.i which may beimplemented in physically distinct computer servers. Conversely, all orany number of the individual dedicated PRS-RP servers 502.i may begrouped and implemented in the single PRS-RP server 112 as indicated bythe dotted line. Only a single provider side repository 506 holding theencryption key “B” may be required in any combined or single PRS-RPserver 112.

Glossary

Operations of the PRS-RP server 112 include processing of requests fromthe browser 118 to servers in the SP 104, and processing of responsesfrom the SP 104 servers to the browser 118. Definitions of terms areprovided in the following glossary for clarity.

Hypertext Transfer Protocol (HTTP)—is an application protocol fordistributed, collaborative, hypermedia systems. HTTP is the foundationof data communication for the World Wide Web. See RFC 2616 for protocoldetails (https://tools.ietf.org/html/rfc2616).

Domain name—(source: Wikipedia: en.wikipedia.org/wiki/Domain_name) Adomain name is an identification string that defines a realm ofadministrative autonomy, authority, or control on the Internet. Domainnames are formed by the rules and procedures of the Domain Name System(DNS). Domain names are used in various networking contexts andapplication-specific naming and addressing purposes. In general, adomain name represents an Internet Protocol (IP) resource, such as apersonal computer used to access the Internet, a server computer hostinga web site, or the web site itself or any other service communicated viathe Internet.

Short form domain—In the context of the PRS Reverse Proxy, this is ashorter version of the domain which is effectively an alias to thedomain name, e.g. “sfdc” may be used as the short form domain for“salesforce.com”.

Primary domain—This is the primary server domain of the application. Inthe case of complex cloud applications, there may be many differenthosts.

Fully Qualified Domain Name (FQDN)—(source: Wikipedia:en.wikipedia.org/wiki/Fully_qualified_domain_name) sometimes alsoreferred as an absolute domain name, is a domain name that specifies itsexact location in the tree hierarchy of the Domain Name System (DNS). Itspecifies all domain levels, including the top-level domain and the rootzone. A fully qualified domain name is distinguished by its unambiguity;it can only be interpreted one way. For example, given a device with alocal hostname myhost and a parent domain name example.com, the fullyqualified domain name is myhost.example.com. The FQDN therefore uniquelyidentifies the device—while there may be many hosts in the world calledmyhost, there can only be one myhost.example.com.

URL (Uniform Resource Locator)—(adapted from source: Wikipedia:en.wikipedia.org/wiki/Uniform_resource_locator)—In computing, a uniformresource locator or universal resource locator (URL) is a specificcharacter string that constitutes a reference to an Internet resource. AURL is technically a type of uniform resource identifier (URI) but inmany technical documents and verbal discussions URL is often used as asynonym for URI. Every URL consists of some of the following: the schemename (commonly called protocol), followed by a colon, two slashes, then,depending on scheme, a server name (exp. ftp, www, smtp, etc) followedby a dot (.), then a domain name (alternatively, an IP address), a portnumber (optional), the path of the resource to be fetched or the programto be run, then, for programs such as Common Gateway Interface (CGI)scripts, a query string, and an optional fragment identifier. The syntaxfor a URL is scheme://domain:port/path?query_string#fragment_id.

Absolute URL—A URL (see above) that is the full format of the URL whichincludes the scheme and domain portions, e.g.https://www.server.com/scripts/dostuff.js is an absolute URL.

Relative URL—A URL (see above) that points to a resource relative to thecurrent location. This format does not have a scheme or domain part,e.g./scripts/dostuff.js is a relative URL.

Multi-Homed Reverse Proxy

Regardless of the method of logging in, SSO with SAML 2.0 as describedabove, or another sign-on process for giving the client access toresources of the service provider, the Reverse Proxy Server mustsubsequently deal with additional challenges as described in thefollowing.

Conventional Reverse Proxy Servers are typically designed andimplemented to provide front-door load balancing for incoming traffic tobe distributed across a plurality of homogeneous web servers that areservicing the same requests.

A new challenge is to use a Reverse Proxy server to act as a gateway toa heterogeneous mix of web servers, each with a unique URL/Domain, and aset of disparate services. As cloud adoption by the enterprise continuesto grow, so does the need to monitor, moderate, and manage access tothese web-based applications and resources, across all protocols. It isimpractical to setup a Reverse Proxy on a cloud by cloud basis.

The problem is further complicated if the connections are utilizingSecure Sockets Layer (SSL) or Transport Layer Security (TLS)connections, for example with HTTP Secure (HTTPS) which is based onencryption using certificates. This is because the Reverse Proxy wouldthen have to serve a single certificate to the client browser on behalfof all back-end cloud services.

Reverse Proxy solutions that exist today would implement only a simpleset of URL rewriting rules that transform one domain address (forexample www.cloudapp.com) to a local address (for examplecloudapp.mycorp.com) and back again. The request URLs are transformedfrom the local URL (i.e. cloudapp.mycorp.com in the present example) tothe real public URL (i.e. www.cloudapp.com in the present example). Theresponse content is then altered to modify any references to the realURL, to the local URL in well known HTML tags that contain URLreferences such as anchor tags, image tags, and script src references.

These reverse proxies however cannot cope with multiple hosts of aservice provider in a single domain. The typical format of domainmapping, i.e. of mapping remotedomain.localdomain.com towww.remotedomain.com will not work for this purpose. Existing reverseproxies may only be capable of being configured to access the World WideWeb (www) hosts of multiple domains corresponding to different serviceproviders.

A problem that occurs with cloud applications of a service provider suchas for example salesforce.com and others, is that content from one pagemay be loaded from multiple hosts in the same domain, where the hostsare not www hosts. The cloud application may also be contained onmultiple hosts on multiple domains that make up the actual content. Inthis situation, the Reverse Proxy function is even more complicated asit needs to keep track of which host and which domain is beingrequested. Ambiguous references may be difficult to resolve as they canrefer to ANY host on ANY domain.

The PRS Reverse Proxy 112 is provided with a Reverse Proxy strategy thatallows it to address this emerging requirement, with an ability for thissingle Reverse Proxy server to provide access across a heterogeneous mixof cloud solutions.

This strategy exploits features of the HTML protocol and the JavaScriptscripting language. HTML provides for URL references being embedded in aHTML document, as well as code written in the JavaScript scriptinglanguage. HTML documents, which may include JavaScript code, arerequested by the client, and subsequently downloaded from the server tothe client. JavaScript code may then be executed on the client when itis called from within a HTML document, with the result that URLreferences may be dynamically generated. HTML and JavaScript arecommonly used elements of client-server systems running on the internet.Details of this and related web technologies may be found in numerousstandards, text books, and articles, for examplehttp://www.w3schools.com/js/, http://en.wikipedia.org/wiki/JavaScript,and http://msdn.microsoft.com/en-us/magazine/cc163419.aspx.

The Reverse Proxy strategy of the PRS Reverse Proxy 112 involves anumber of components, including:

-   -   persistence of state information and history of the sessions        established by the browser to specific cloud services;    -   a heuristics engine for determining the correct services to        redirect requests to if the PATH'S are simply indirect        references such as “/index.html” rather than fully qualified        path names such as www.cloudapp.com/index.html;    -   a URL re-writing grammar that allows the client browser to        follow all embedded links and URL references across the        plurality of back-end servers.

FIG. 6 illustrates an exemplary multi-host Reverse Proxy system 600 toyet another embodiment of the invention, including the enterpriseinstallation 102 of FIG. 1 which comprises the client 110, thePRS-Reverse Proxy 112, and the optional firewall 114 and the serviceprovider (SP) 104, which comprises individual hosts 602, 604, 606, 608,and 610. In this example. the individual hosts are also referred to bytheir domain names of a specific service provider, i.e. salesforce.com.The individual hosts are:

-   -   www.salesforce.com, the individual host 602, which is the root        host of salesforce.com;    -   login.salesforce.com, the individual host 604, which may be a        login server of salesforce.com;    -   na12.salesforce.com, the individual host 606, which may provide        some applications of salesforce.com;    -   c.na12.salesforce.com, the individual host 608, which may        provide common components of applications of salesforce.com; and    -   na12.static.com, the individual host 610, which may provide        support for the applications of the individual host 606        (na12.salesforce.com) and the individual host 608        (c.na12.salesforce.com), but belongs to a different domain        (static.com), not salesforce.com.

It is understood that the domain names of these five individual hostsare examples which are shown for illustrative purposes, and theinvention is not limited to any particular number of individual hosts,or hosts having any specific domain names. It is further noted that thedivision of facilities and resources in a service provider, such assalesforce.com, is under control of the service provider and outside thescope of the present invention. It is however an objective of thepresent invention to provide Reverse Proxy capabilities in the PRS-RP112 to match the domain and host layout of the service provider.

The client 110, by way of his browser 118, is enabled through the PRS-RP112 to log into the SP 104, for example using the SSO method of signingin as described above or by another method.

Accessing the individual hosts of the SP 104 through the PRS-RP 112 maybe facilitated by a URL format convention described in the following.

The PRS Reverse Proxy 112 is designed for multiple domains and multiplehosts. The PRS-RP 112 itself has a single host name in the enterprise102, for example “myrevproxy.yourcorp.com”, shown in FIG. 6 withreference numeral 612.

The link to a resource in the SP 104 from the client 110 would then bethe hostname of the PRS-RP 112 followed by:

-   -   a domain short form, for example “sfdc” representing        “salesforce.com”, i.e. the service provider 104;    -   a host name, for example “na12” representing the individual host        606 in the SP 104;    -   and the rest of the normal URL path.

An example according to this convention would thus be:

“https://myrevproxy.yourcorp.com/sfdc/na12/001/o”, where:

-   -   myrevproxy.yourcorp.com is the single host name (612)        identifying the PRS-RP 112;    -   the first element in the path identifies the domain within the        SP 104 in short form, i.e. sfdc;    -   the second element in the path identifies the individual host by        its actual name, i.e. “na12”;    -   the rest of the path is the same as it would be going directly        to the host, e.g. “/001/o”, the same expression as in        https://na12.salesforce.com/001/o which would be used if one        were to access the host directly without Reverse Proxy.

A benefit of using the single enterprise host name is that only one SSLcertificate is required for the Reverse Proxy to support a plurality ofdomains and hosts. A potential drawback of this scheme could be that anycustomizations to the cloud applications that examine the URLs willpotentially be affected as they will need to change the URL format theyare using to call other elements. But the PRS Reverse Proxy providesheuristics to recover from these types of requests, as described in thefollowing.

More and more cloud applications are using dynamic JavaScript togenerate their content. This poses big problems when it comes to dealingwith applications with multiple hosts and domains as resolving the hostand domain properly can be troublesome.

When content is retrieved by the PRS-RP 112 from the server (a host ofthe SP 104), URLs must be changed before forwarding the content to theclient 110. But there is generally not only a simple URL to change fromthe original URL (www.salesforce.com in this example) to the localReverse Proxy reference, i.e. myrevproxy.yourcorp.com/sfdc/www as in theexample of FIG. 6.

A method by which the PRS Reverse Proxy deals with dynamic JavascriptURLs is to intercept the actual Javascript calls in an applicationcontext, which is described in detail in the section “Process forPreserving JavaScript URLs” below.

The situation may be especially difficult when the URL is a relativelink. When the PRS Reverse Proxy 112 receives a relative request it doesknow for which domain or host the request is for. In that case there isa heuristic algorithm (see the section Process for Resolving the Domainbelow) for determining the correct server to which the request should bemapped.

FIG. 7A shows a data flow diagram 700 as an example of URL manipulationsin the PRS Reverse Proxy 112, including the Browser 118 of the Client110 connected to a Cloud Application 702 of the Service Provider 104through the PRS Reverse Proxy 112 which includes a Request ProcessingFunction 704 and a Response Processing Function 706.

In the example shown, the Client 110 obtains a desired HTML page fromthe Cloud Application 702 through a sequence of four messages asillustrated in FIG. 7A as:

a HTTP Request 708 from the Client 110 to the PRS-RP 112;a modified HTTP Request 710 from the PRS-RP 112 to the Cloud Application702;a HTML page 712 returned from the Cloud Application 702 to the PRS-RP112; anda modified HTML page 714 from the PRS-RP 112 to the Client 110.

The normal flow of the reverse proxy processing, shown in FIG. 7A, witha reverse proxy URL reference in the form of the HTTP Request 708 (forexample, https://revproxy.yourcorp.com/cloudapp/www/home.html),originating from the user's browser 118. The HTTP Request 708 includes aRequest URL 716 (i.e./cloudapp/www/home.html), which is a relative URL,and a Host header 718 (i.e. revproxy.yourcorp.com).

The Request Processing Function 704 of the PRS-RP 112 modifies theRequest URL 716 and the Host header 718 of the HTTP request 708, into amodified Request URL 720 (i.e./home.html) and a modified Host header 722(i.e. www.cloudapp.com) respectively of the modified HTTP Request 710.The modified HTTP Request 710 (i.e. https://www.cloudapp.com/home.html)may also be considered as an absolute URL which includes the scheme anddomain portions to point to the real URL of the cloud application 702.

As illustrated, the HTTP Request 708 specifies the desired HTML page,but the HTTP Request 708 is addressed to the URL of the PRS-RP 112 Host“revproxy.yourcorp.com”, wherein “cloudapp” is the short name of thedomain of the Cloud Application 702, “www” is the short name of its hostURL of the SP 104.

In the Request Processing Function 704, the HTTP Request 708 is modifiedinto the modified HTTP Request 710 which is addressed to the URL of thehost of the Cloud Application 702 “www.cloudapp.com”. Elements of theHTTP Request 708 that are modified to obtain the modified HTTP Request710, are shown in a bold underlined type style in FIG. 7A.

The HTML page 712 that is returned from the Cloud Application 702 inresponse to the modified HTTP Request 710, is then modified in theResponse Processing Function 706 of the PRS-RP 112, and the modifiedHTML page 714 returned to the Browser 118 of the Client 110. An exampleof the HTML page 712 and the corresponding modified HTML page 714 areshown in FIG. 7B.

The cloud application 702 then returns the requested page content 712.The Response Processing function 706 of the PRS-RP 112 then modifies thereturned page content 712 into a modified page content 714 by changingall relative and absolute URL references in HTML tags (e.g. src and hrefportions of tags, such as “<a href=”/link/here“>A Link</a>”) intomodified HTML tags (e.g. <a href=“/cloudapp/www/link/here”>A Link</a>”).All known JavaScript function calls specific to the cloud application,for instance “loadUrl(‘/content/script.js’)” are changed into JavaScriptfunction calls (i.e. “loadUrl(‘/cloudapp/www/content/script.js)”). Themodified page content 714 is loaded by the user's browser, which willthen load all references on the modified page and make further requeststhrough the reverse proxy, and so on.

FIG. 7B shows code examples of the HTML page 712, and the modified HTMLpage 714, indicating the modifications performed in the ResponseProcessing Function 706. Corresponding code lines containing absoluteand relative URLs in the page content to be modified are indicated byarrows passing through the Response Processing Function 706.

Specifically:

-   -   line 3, which is a href statement: the term /cloudapp/www is        removed from the absolute URL;    -   line 5, which is a src statement: the term        revproxy.yourcorp.com/cloudapp/www/ in the URL, which is the        server name of the PRS-RP 112 followed by the short names of the        domain of the Cloud Application 702 (cloudapp) and of its host        URL (www), is replaced with www.cloudapp.com, which is the URL        of the host of the cloud application; and    -   both lines 8 and 10, which contain relative URLs: the term        /cloudapp/www is removed.

FIG. 7C shows a flowchart 750 of the Response Processing Function 706,with 3 main steps:

-   752: Change static host and domain references to reverse proxy host    and domain;-   754: Change static content references to prefix all URLs references    with /shortdomain/host format; and-   756: Change dynamic content references (e.g JavaScript) to prefix    all URLs references with /shortdomain/host format.

The processing operations described in FIG. 7A above are straightforward for the reverse proxy. The case of JavaScript dynamic generationof URLs however is problematic with cloud applications and needs to behandled as a special exception case. The response processing (modifyingthe content of the HTML page 712 into the modified HTML page 714)assumes that the PRS-RP 112 is able to properly identify all relevantURLs that need to be changed.

In the case of dynamic URLs that are generated at run time inJavaScript, the reverse proxy typically may not know that a url is beinggenerated. This may result in a relative request that is coming from theuser's browser that does not have the expected reverse proxy format ofhttps://reverseproxydomain.com/appshortform/host/path. In this exceptioncase, the heuristic algorithm of the “Process for Preserving JavaScriptURLs” described below, is used to determine which domain and thereforewhich short form is to be used, and which host should used in the pathof the URL to properly be processed.

Process for Resolving the Domain

FIG. 8 shows a domain resolution method 800 according to anotherembodiment of the invention, performed in the PRS-RP 112 for resolving acurrent URL of an HTTP request, comprising steps:

-   802 “Receive HTTP request”;-   804 “Resolve default known pattern”;-   806 “Use application base domain name for guessing starting point”;-   808 “Use content paths definitions to determine host”;-   810 “Use referrer URL”; and-   812 “Last resort default”.

At the step 802 “Receive HTTP request”, a HTTP request from the client110 is received by the PRS-RP 112. The request is assumed to have a HTTPheader pattern of the following form: “https://<PRS Reverse Proxy HostFQDN>/<DOMAINSHORTFORM>/<HOSTSHORTFORM>/”. This HTTP header pattern hasthree components:

<PRS Reverse Proxy Host FQDN> is the URL of the PRS Reverse Proxy 112,also referred to as the domain name of the PRS Reverse Proxy computer112;<DOMAINSHORTFORM> is the short form of the URL of the root host in theservice provider SP 104, also referred to as the short form of theprimary domain name of the service provider;<HOSTSHORTFORM> is the short form of the URL of the intended, and thusthe selected, host in the service provider SP 104, also referred to asthe short form host name.

The terms “host” and “host computer” are interchangeable, both referringto a server computer, that is a component of the service provider 104.

In addition the HTTP request header may also contain a path namespecifying the requested resource or file on the host. The sequence/DOMAINSHORTFORM/HOSTSHORTFORM/path/may be considered to be an expandedpath. The DOMAINSHORTFORM and the HOSTSHORTFORM are converted into ahost.domain address by looking up the translation from short form namesto real names in a configuration file which contains a domain and hostconfiguration table. Elements of the path or the expanded path areseparated by forward slash characters “/”.

The Step 804 “Resolve default known pattern” is based on an assumptionthat the components of the HTTP header pattern are correct.

FIG. 9 shows a sample domain and host configuration table. A segment ofa PRS Reverse Proxy configuration file for the salesforce.com domain isillustrated, which indicates that the short form of the URL ofsalesforce.com is “sfdc”, and includes a “hostslist” which lists shortforms (names) of hosts in salesforce.com. For each of the hosts, a“scheme” is provided which indicates the protocol to be used fortransmitting the request to the respective host. While only one examplePRS Reverse Proxy configuration file is shown, it is understood that thePRS-RP 112 may comprise a plurality of PRS Reverse Proxy configurationfiles for a corresponding plurality of service provider domains.

In the step 804, the HTTP header pattern is matched against theconfigured patterns. If the HTTP header pattern matches any of theconfigured patterns, i.e. if both the domain short form (e.g. sfdc) andthe host short form (e.g. www) are found in the PRS Reverse Proxyconfiguration file, the HTTP header pattern is considered valid (exit“OK” from step 804), and the domain resolution process is finished,otherwise the step 806 is executed next.

The step 806 “Use application base domain name for guessing startingpoint” is executed when the HTTP header pattern is not matched preciselyin any PRS Reverse Proxy configuration file.

First it is assumed that the domain matches the primary domain of thecloud application as a starting point, i.e. sfdc in the present example.If the domain (sfdc) is known but the host is not known, then a homeserver for the cloud application instance contained in the received HTTPrequest may be have been configured in a content paths definitions file(see example in FIG. 10) of the PRS Reverse Proxy 112 configurationfiles 1228 (FIG. 12). The home server, identified as “$HOME” in the acontent paths definitions file, is the default host name for a specifiedinstance of a specific cloud application. In the case of salesforce.comfor example, the home server is based on the organization identity (ID)of the enterprise installation 102 to which the PRS-RP 112 belongs.

If host and domain are thus resolved in the step 806 (exit “OK” fromstep 806), the domain resolution process is finished, otherwise the step808 is executed next.

At the step 808 “Use content path configuration to determine host”,content path overrides are applied if they have been defined in acontent path configuration file to be used as hints for the correctserver host. The pattern matching of the relative URL is then used toset the domain and host to know values. The $HOME variable in the samplecontent path configuration file is replaced with the home host definedin the configuration file or may be determined dynamically if it is notdefined in the configuration file.

The “home server” for the application (e.g. na12.salesforce.com, whenuser is logged in) is configured by the application organizationidentifier (essentially by the application instance). When the user logsinto salesforce.com for example through login.salesforce.com, they willbe redirected to their “home” server. The PRS-RP 112 has a list ofpossible home servers and remembers which home server the user haslogged into, dynamically setting it if not defined. Similarly for othercloud applications, the login redirects to the primary server used bythe application.

FIG. 10 shows an excerpt of a sample content paths definitions file.

For example, the body of the HTTP request may contain a reference to aspell checking application, expressed as a relative path“src=/spellcheck/”. In the step 810, the host=“spell-sjl” and thedomain=“sfdc” are found along with the application “spellcheck” in thesecond line of the sample content paths definitions file of FIG. 10.

If the spellcheck application had been directly requested in the HTTPheader (instead of only referenced in the body of the HTTP request), thesame host name=“spell-sjl” and the domain corresponding to the domainshort form “sfdc” would already have been found in the step 804 above bysearching the hosts list of the domain and host configuration (FIG. 9)under the salesforce.com domain (domain short form=“sfdc”), without theneed for using the content path definitions to determine this domain andhost.

The method of creating a short form “nickname” and embedding it in therewritten (expanded) path allows the PRS Reverse Proxy 112 to quicklyascertain which back-end server it is actually redirecting to, byreferencing an XML configuration file of which the domain and hostconfiguration is an excerpt (FIG. 9). This is especially useful whenworking with the new generation of browsers which establish a pluralityof simultaneous connections in order to process requests for reading webpages.

Requests for specific content may generate relative requests that do notinclude the domain and host short forms. For example, if a request comesto the PRS Reverse Proxy 112 for “/spell-sjl/spellcheck.jsp”, theconfiguration file is checked for content paths that match. If the pathmatches, the host and domain for that resource are used. The confusionin a multihomed system is that the relative path may belong to three orfour different possible hosts.

If host and domain are thus resolved in the step 808 (exit “OK” fromstep 808), the domain resolution process is finished, otherwise the step810 is executed next.

At the step 810 “Use referrer URL”, the referrer URL header in the HTTPrequest may be used as domain and host hints. If a relative URL wasinvoked from a previous page, then it is likely that it is in referenceto the same server. This assumption is not 100% accurate, but useful inguessing. Stored links in browser shortcuts, or manipulations fromprograms may cause invalid or missing referrer headers in the HTTPrequest.

If host and domain are thus resolved in the step 810 (exit “OK” fromstep 810), the domain resolution process is finished, otherwise the step812 is executed next.

The step 812 “Last resort default” is provided as a last resort. If allprevious attempts at identifying the appropriate host and domain havefailed, the request will be forwarded to the www host of the applicationdomain which is the same as the root domain.

In this way host and domain are always resolved in the default step 812and the domain resolution process is finished. There is no failure path.

The steps 804 to 812 of resolving the URL in the header of an HTTPrequest is performed in a Forward URL Translator module of the PRS-RP112 (see Forward URL Translator 1218 in FIG. 12).

The response of a forwarded HTTP request from the PRS-RP 112 to aserver, will be directed to the PRS-RP 112, not the client device 110.The PRS-RP 112 then has to replace the address (URL) in the responsewith the URL of the client device 110 in a conventional manner (notshown in detail here). Connection state information stored in persistentstorage of the PRS-RP 112 (see “Connection state information” 1224 inFIG. 12) is used to correlate the response with the request, thusproviding the identity (URL) of the requesting client device 110.

The process of handling the URL transformation for the server response,that is replacing the URL in a server response, is performed in aReverse URL Translator module of the PRS-RP 112 (see Reverse URLTranslator 1220 in FIG. 12).

Process for Preserving JavaScript URLs

The PRS Reverse Proxy 112 is designed with application context awarereplacements for JavaScript calls in order to deal with dynamic URLgeneration.

Persistent state information and session history is created byintercepting HTML code that is sent from the service provider to theclient, and storing relevant relevant data, for example JavaScript callsthat directly or indirectly create a URL. For a given cloud applicationanalysis has been done to determine those JavaScript calls that eitherdirectly or indirectly create a URL. This is a key part of being able tomake the PRS Reverse Proxy 112 work with salesforce.com and other cloudapplications.

A heuristics engine in the PRS Reverse Proxy 112 then changes thoseJavaScript calls with the local Reverse Proxy equivalent before theJavaScript is actually executed on the browser. In this way when therequests are then made from the browser, the correctly formatted URL isused.

For example, the code may contain a navigateToUrl( )function. Theapplication makes a call to this JavaScript function to change thebrowser URL location. This function may take arguments, for example,both a host parameter and a path parameter (e.g.navigateToUrl(host,path)).

If the normal call that was generated in the code was, for example:

navigateToUrl(‘na12.salesforce.com’, ‘/services/ui/getConfig’),the PRS Reverse Proxy would then change the javascript call to:navigateToUrl(‘myrevproxy.yourcorp.com’,‘/sfdc/na12/services/ui/getConfig’).

Generally speaking, when any of a particular class of JavaScriptfunctions is executed by the client 110, where the resulting actionincludes navigation to one of a plurality of hosts of the SP 104, theHTML code containing calls to such functions must be modified by PRS-RP112. In order for this navigation to work properly through the PRS-RP112, the arguments of every call to such JavaScript functions aremodified to:

-   -   replace direct URL references to hosts with the single URL of        the PRS-RP 112, e.g. ‘myrevproxy.yourcorp.com’, and    -   expand paths to identify the service provider host by prepending        the short form identifying the domain, e.g. ‘/sfdc’, and the        hostname, e.g. ‘/na12’.

FIG. 11 shows a flowchart of a Process for Preserving JavaScript URLs1100, including steps:

-   1102 “Receive HTTP page from server”;-   1104 “Find JavaScript calls”;-   1106 “Next JavaScript call”;-   1108 “URL argument?”;-   1110 “Determine server domain”;-   1112 “Look up short form name”;-   1114 “Replace server domain with URL of Reverse Proxy”;-   1116 “Pre-pend short form name to path”;-   1118 “Last JavaScript call?”; and-   1120 “Transmit HTML page to client”.

The Process for Preserving JavaScript URLs 1100 runs in a ContentModification process (see Content Modifier 1216, FIG. 12) of the PRSReverse Proxy 112 and, briefly summarized, modifies each HTML pagereceived from a server (step 1102), by:

-   -   sequentially scanning the text of the page (steps 1104 to 1118);    -   finding JavaScript calls with URL arguments (steps 1106, 1108);    -   changing URLs in the arguments (steps 1110 to 1116); and    -   sending the modified HTML page to the client (step 1120).

The Process for Preserving JavaScript URLs 1100 is not limited to HTML.It may also be used to support JavaScript Object Notation (JSON). Thereare cases in Asynchronous JavaScript and XML (AJAX) technology wherecall responses are JSON, or even HTML embedded in parts of JSON content.The scope of the processing functions of the PRS-RP 112 is not limitedby content type, but includes all standard content types that requireURL re-mapping, for example XML, JSON, XHTML, Simple Object AccessProtocol (SOAP) etc. It is also possible to interpret and modifyrequests and content of non-standard, i.e. proprietary, protocols usedin certain cloud application systems.

In summary, javascript dynamic processing is performed by replacingstrings as shown in the flowchart 1100 of FIG. 11. The “src” and “href”parts of all standard HTML tags are altered first. Then embedded flashurls are converted, then any javascript “window.location.href=”statements, followed by individual calls to different cloud applicationspecific javascript calls. Some of these are simple single parametercalls. Others are multi-parameter calls where it is necessary toidentify which of the parameters are in fact relative URLs that need tobe changed.

FIG. 12 shows a block diagram 1200 of the PRS Reverse Proxy 112,including a Processor 1202, a Computer Memory 1204, and a PersistentStorage unit 1206.

The Processor 1202 may be any commercial processor capable of executingprograms under an operating system such as, but not limited to, Linux,Microsoft Windows, or Mac Operating System 10 (OSX) for example,comprising a Central Processing Unit (CPU) 1208, a Network Input/Output(I/O) system 1210 and a Command Interface 1212.

The CPU 1208 may be any of a number of commercial processorimplementations, including a multi-processor. The Network Input/Output(I/O) system 1210 provides an interface facility to the Internet 108 viathe optional Firewall 114, the Private Network 116, or directly to theClient 110, see FIGS. 1 and 6. The Command Interface 1212 may include akeyboard, mouse, and visual interface, as well as removable storagedevices, or any other hardware suitable as means for controlling asoftware configuration as well as the operations of the PRS ReverseProxy 112.

The Processor 1202 is connected to the Computer Memory 1204 which ispreferably a non-transitory memory device such as dynamic memory (DRAM)capable of storing software programs and related data. Software programswhich include computer executable instructions are stored in theComputer Memory 1204 include: an Assertion Processing Module 1214 forrevising assertions (see FIG. 4); a Content Modifier 1216 comprisingprograms that implement the Response Processing Function 706 of FIG. 7A,including the Process for Preserving JavaScript URLs 1100 of FIG. 11; aForward URL Translator 1218 comprising programs that implement theDomain Resolution Method 800 of FIG. 8 to replace the URLs in requestsfrom the client 110, as well as the Request Processing Function 704 ofFIG. 7A; and a Reverse URL Translator 1220 comprising programs thatimplement corresponding functions for replacing explicit server URLreferences in responses from the servers in the SP 104 with the URL ofthe PRS-RP 112 and the server's short name as described above.

The Request Processing Function 704 and the Response Processing Function706 of FIG. 7A are performed in the Forward URL Translator 1218 and theReverse URL Translator 1220 respectively.

The Processor 1202 is also connected to the Persistent Storage unit 1206which may be implemented in any of a number of persistent storagetechnologies including, but not limited to, for example a hard disk or aflash drive. Data stored in the Persistent Storage unit 1206, may bestored simultaneously in the Computer Memory 1204 for periods while itis actively being used by the processor 1202, but is also preferablystored in the Persistent Storage unit 1206 for reliability.

The Persistent Storage unit 1206 is used for storing persistentinformation, primarily configured information, such as Keys andCertificates in a Key Store 1222 to support the Assertion Processingmodule 1214 used for revising assertions (FIG. 4). The PersistentStorage unit 1206 is preferably further used for storing ConnectionState Information 1224, a Session History 1226 for recording sessiondata of server applications accessed by the one or more clients 110. ThePersistent Storage unit 1206 is preferably further used for storing oneor more PRS-Reverse Proxy Configuration files 1228 which include forexample the content paths definitions file, an excerpt of which is shownin FIG. 10 and the domain and host configuration file, an excerpt ofwhich is shown in FIG. 9. The Assertion Processing module 1214 and thedata stored in the Key Store 1222, form a first computer group ofelements 1230, as indicated in FIG. 12. Programs of the Content Modifier1216, the Forward URL Translator 1218, and the Reverse URL Translator1220 collectively and the data stored in the Connection StateInformation 1224, the Session History 1226, and the Configuration files1228, form a second group of computer elements 1232, as indicated inFIG. 12. The first group of computer elements 1230 support theoperations of the single-sign-on process 200 of FIG. 2, while the secondgroup of computer elements 1232 support operations of the multi-hostReverse Proxy system 600 of FIG. 6.

While examples used in describing embodiments of the PRS Reverse Proxyserver 112 have been based on HTTP requests using HTTP GET messages, andtheir responses, it is understood that the described techniques formodifying URLs and addresses are equally applicable to other HTTPmessage forms such as HTTP POST for example, and other protocols such asXML, JSON and others as outlined above.

Although the embodiments of the invention have been described in detail,it will be apparent to one skilled in the art that variations andmodifications to the embodiment may be made within the scope of thefollowing claims.

1. A method for providing a resource from one of a plurality of serviceprovider hosts to a client device through a reverse proxy computer,comprising: employing at least one processor for: receiving a requestfrom the client device in the reverse proxy computer, the requestincluding a header comprised of: a domain name of the reverse proxycomputer; a short form domain name representing a selected serviceprovider domain (domain); a short form host name representing a selectedservice provider host (host) in the t selected domain; and a path namefor locating the resource on the host; translating the short form domainname into a domain name of the host; translating the short form hostname into a host name of the host; and generating a modified request fortransmission to the server provider host, the modified requestincluding: the host name, the domain name, and the path name.
 2. Themethod of claim 1, wherein the short form domain name is an alphanumericstring preceded by a forward slash character (“/”), and the short formhost name is another alphanumeric string preceded by another forwardslash character (“/”).
 3. The method of claim 1, further comprising:modifying a document, received in the reverse proxy from the hostcomputer, into a modified document, including: finding a reference tothe domain name of the host in the document; and replacing the referenceto the domain name of the host, with the domain name of the reverseproxy, followed by a forward slash character (“/”) and the short formname of the host; transmitting the modified document to the clientdevice.
 4. The method of claim 1, wherein the request from the clientdevice is a Hypertext Transfer Protocol (HTTP) GET message.
 5. Thereverse proxy computer of claim 1, wherein the request from the clientdevice is contained in a Hypertext Transfer Protocol (HTTP) POSTmessage.
 6. The method of claim 3, wherein the document is a HypertextMarkup Language (HTML) document.
 7. The method of claim 6, furthercomprising: finding within the document a subroutine call having asarguments a Universal Resource Locator (URL) of one of the plurality ofthe service provider hosts and a path name; and replacing saidsubroutine call with a modified subroutine call, comprising: replacingsaid URL with the URL of the reverse proxy; and generating a modifiedpath name by inserting another forward slash character (“1”) followed bythe short form name of said one of the plurality of the service providerhosts in front of the path name.
 8. The method of claim 7, furthercomprising repeating the steps finding and replacing said subroutine forall subroutine calls in the document.
 9. The method of claim 7, whereinthe subroutine call is a JavaScript function call.
 10. The method ofclaim 1, further comprising: receiving a request from the client in thereverse proxy, the request including a header which does not correspondto any pattern found in a configuration file of the reverse proxy;resolving the request by performing the following steps until theselected domain and the selected host for obtaining the resource isdetermined, including: searching a short form name in the header andtranslating the short form name into the selected domain name, andprovided said short form name is found in the configuration file,searching a path name in a content paths definitions file of the reverseproxy to determine the selected host, provided the path name is found inthe content paths definitions file, thereby finding the selected domainand the selected host; and generating a modified request fortransmission to the server, the modified request including the selecteddomain name, the selected host name and the path name, provided theselected domain and the selected host have been determined.
 11. Themethod of claim 10, wherein the resolving further comprises determiningboth the selected domain and the selected host from a referrer URL thatis located in the request, thereby finding the selected domain and theselected host.
 12. The method of claim 11, the resolving furthercomprises using a home domain of the service provider as the selecteddomain and a world wide web (www) server as the selected host, therebydetermining the selected domain and the selected host.
 13. A reverseproxy computer for providing a resource from one of a plurality ofservice provider hosts to a client device, the reverse proxy computercomprising: a processor; and a memory having computer readableinstructions stored thereon, causing the processor to: receive a requestfrom the client device in the reverse proxy computer, the requestincluding a header comprised of: a domain name of the reverse proxycomputer; a short form domain name representing a selected serviceprovider domain (domain); a short form host name representing a selectedservice provider host (host) in the selected domain; and a path name forlocating the resource on the host; translate the short form domain nameinto a domain name of the host; translate the short form host name intoa host name of the host; and generate a modified request fortransmission to a service provider, the modified request including: thehost name, the domain name, and the path name.
 14. The reverse proxycomputer of claim 13, wherein the short form domain name is analphanumeric string preceded by a forward slash character (“/”), and theshort form host name is another alphanumeric string preceded by anotherforward slash character (“/”).
 15. The reverse proxy computer of claim13, further comprising computer readable instructions stored in thememory, causing the processor to: modify a document, received in thereverse proxy from the host computer, into a modified document,including: finding a reference to the domain name of the host in thedocument; and replacing the reference to the domain name of the host,with the domain name of the reverse proxy, followed by a forward slashcharacter (“/”) and the short form name of the host; transmit themodified document to the client device.
 16. The reverse proxy computerof claim 13, wherein the request from the client device is a HypertextTransfer Protocol (HTTP) GET message.
 17. The reverse proxy computer ofclaim 13, wherein the request from the client device is contained in aHypertext Transfer Protocol (HTTP) POST message.
 18. The reverse proxycomputer of claim 15, wherein the document is a Hypertext MarkupLanguage (HTML) document.
 19. The reverse proxy computer of claim 15,wherein the document is an Extensible Markup Language (XML) document.20. The reverse proxy computer of claim 15, wherein the document is aJavaScript Object Notation (JSON) document.
 21. The reverse proxycomputer of claim 18, further comprising computer readable instructionsstored in the memory, causing the processor to: find within the documenta subroutine call having as arguments a Universal Resource Locator (URL)of one of the plurality of the service provider hosts and a path name;and replace said subroutine call with a modified subroutine call,including: replacing said URL with the URL of the reverse proxy; andgenerating a modified path name by inserting another forward slashcharacter followed by the short form name of said one of the pluralityof the service provider hosts in front of the path name.
 22. The reverseproxy computer of claim 21, wherein the subroutine call is a JavaScriptfunction call.
 23. A reverse proxy computer for providing a resourcefrom one of a plurality of service provider hosts to a client device,the reverse proxy computer comprising: a processor; a memory havingcomputer readable instructions stored thereon for execution by theprocessor, forming: a forward Universal Resource Locator (URL)translator module having instructions for: receiving a request from theclient device in the reverse proxy computer, the request including aheader comprised of: a domain name of the reverse proxy computer; ashort form domain name representing a selected service provider domain(domain); a short form host name representing a selected serviceprovider host (host) in the selected domain; and a path name forlocating the resource on the host; translating the short form domainname into a domain name of the host; translating the short form hostname into a host name of the host; and generating a modified request fortransmission to the server provider host; the modified requestincluding: the host name, the domain name, and the path name.
 24. Thereverse proxy computer of claim 23, wherein the short form domain nameis an alphanumeric string preceded by a forward slash character (“/”),and the short form host name is another alphanumeric string preceded byanother forward slash character.
 25. The reverse proxy computer of claim23, further comprising a content modifier module having computerreadable instructions stored in the memory for: modifying a document,received in the reverse proxy from the host computer, into a modifieddocument, including: finding a reference to the domain name of the hostin the document; and replacing the reference to the domain name of thehost, with the domain name of the reverse proxy, followed by a forwardslash character (“/”) and the short form name of the host; transmittingthe modified document to the client device.
 26. The reverse proxycomputer of claim 23, wherein the request from the client is a HypertextTransfer Protocol (HTTP) GET message.
 27. The reverse proxy computer ofclaim 23, wherein the request from the client is contained in aHypertext Transfer Protocol (HTTP) POST message.
 28. The reverse proxycomputer of claim 25, wherein the document is a Hypertext MarkupLanguage (HTML) document.
 29. The reverse proxy computer of claim 28,the content modifier module further having instructions for: findingwithin the document a subroutine call having as arguments a UniversalResource Locator (URL) of one of the plurality of the service providerhosts and a path name; and replacing said subroutine call with amodified subroutine call by: replacing said URL with the URL of thereverse proxy; and generating a modified path name by inserting anotherforward slash character followed by the short form name of said one ofthe plurality of the service provider hosts in front of the path name.30. The reverse proxy computer of claim 29, wherein the subroutine callis a JavaScript function call.
 31. The reverse proxy computer of claim23, the forward URL translator module further having instructions for:receiving a request from the client in the reverse proxy, the requestincluding a header which does not correspond to any pattern found in aconfiguration file of the reverse proxy; resolving the request byperforming the following steps until the selected domain and theselected host for obtaining the resource is determined, including:searching a short form name in the header and translating the short formname into the selected domain name, and provided said short form name isfound in the configuration file, searching a path name in a contentpaths definitions file of the reverse proxy to determine the selectedhost, provided the path name is found in the content paths definitionsfile, thereby finding the selected domain and the selected host; andgenerating a modified request for transmission to the server, themodified request including the selected domain name, the selected hostname and the path name, provided the selected domain and the selectedhost have been determined.
 32. The reverse proxy computer of claim 31,the forward URL translator module further having instructions fordetermining both the selected domain and the selected host from areferrer URL that is located in the request, thereby finding theselected domain and the selected host.
 33. The reverse proxy computer ofclaim 32, the forward URL translator module further having instructionsfor using a home domain of the service provider as the selected domainand a world wide web (www) server as the selected host, therebydetermining the selected domain and the selected host.